home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-01-01 | 7.2 KB | 80 lines | [TEXT/ttxt] |
- These are the new changes to the MacBinary Standard, as generally agreed
- upon in the MacBinary II Conference 6/21/87, and as changed in the followup
- conference 6/28/87. Revised 7/24/87 to reflect suggestions and clarifications
- that came later, and to include all necessary information needed from the
- original MacBinary standard document to implement MacBinary II.
-
- The new standard will be very similar to the original MacBinary standard as
- described in [MacBinary Standard]. (Reading the original standard is
- recommended for a full understanding of implementation and philosophy
- behind the MacBinary I and II formats.) The binary format consists of a
- 128-byte header containing all the information necessary to reproduce the
- document's directory entry on the receiving Macintosh; followed by the
- document's Data Fork (if it has one), padded with nulls to a multiple of
- 128 bytes (if necessary); followed by the document's Resource Fork (again,
- padded if necessary). The lengths of these forks (either or both of which
- may be zero) are contained in the header.
-
- The format of the header for MacBinary II is as follows:
-
- Offset 000-Byte, old version number, must be kept at zero for compatibility
- Offset 001-Byte, Length of filename (must be in the range 1-63)
- Offset 002-1 to 63 chars, filename (only "length" bytes are significant).
- Offset 065-Long Word, file type (normally expressed as four characters)
- Offset 069-Long Word, file creator (normally expressed as four characters)
- Offset 073-Byte, original Finder flags
- Bit 7 - Locked.
- Bit 6 - Invisible.
- Bit 5 - Bundle.
- Bit 4 - System.
- Bit 3 - Bozo.
- Bit 2 - Busy.
- Bit 1 - Changed.
- Bit 0 - Inited.
- Offset 074-Byte, zero fill, must be zero for compatibility
- Offset 075-Word, file's vertical position within its window.
- Offset 077-Word, file's horizontal position within its window.
- Offset 079-Word, file's window or folder ID.
- Offset 081-Byte, "Protected" flag (in low order bit).
- Offset 082-Byte, zero fill, must be zero for compatibility
- Offset 083-Long Word, Data Fork length (bytes, zero if no Data Fork).
- Offset 087-Long Word, Resource Fork length (bytes, zero if no R.F.).
- Offset 091-Long Word, File's creation date
- Offset 095-Long Word, File's "last modified" date.
- Offset 099-Word, length of Get Info comment to be sent after the resource
- fork (if implemented, see below).
- *Offset 101-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
- *Offset 116-Long Word, Length of total files when packed files are unpacked.
- This is only used by programs that pack and unpack on the fly,
- mimicing a standalone utility such as PackIt. A program that is
- uploading a single file must zero this location when sending a
- file. Programs that do not unpack/uncompress files when
- downloading may ignore this value.
- *Offset 120-Word, Length of a secondary header. If this is non-zero,
- Skip this many bytes (rounded up to the next multiple of 128)
- This is for future expansion only, when sending files with
- MacBinary, this word should be zero.
- *Offset 122-Byte, Version number of Macbinary II that the uploading program
- is written for (the version begins at 129)
- *Offset 123-Byte, Minimum MacBinary II version needed to read this file
- (start this value at 129 129)
- *Offset 124-Word, CRC of previous 124 bytes
-
- *This is newly defined for MacBinary II.
-
- All values are stored in normal 68000 order, with Most Significant Byte
- appearing first then the file. Any bytes in the header not defined above
- should be set to zero.
-
- The original MacBinary format was ammended to include the sending of the FCMT
- (Get Info comment) after the resource fork was sent, if the length for such
- comment, given in offset 99, is not zero. To the best of our knowledge, no
- program has implemented this feature, due to Apple's stated position that no
- program should read or write these comments. The definition remains in
- MacBinary II, so that should Apple ever provide a documented way of reading and
- writing these comments, terminal programs will be able to take advantage of
- this feature.
-
- All Finder flags and information would be uploaded, however, a downloading
- program should clear the Finder flag bits of
- 0 - Set i